BUNDESREPUBLIK ® Offenlegungsschrift 

DEUTSCHLAND „ f QO 15 114 A 1 




DEUTSCHES 
PATENT- UND 
MARKENAMT 



® 



@ Aktenzeichen: 
@ Anmeldetag: 
® Offenlegungstag: 



® Int. CI. 7 : 

G 06 F 17/50 

B62 D 65/00 



10015 114.0 
28. 3.2000 
4. 10. 2001 



in 

o 
o 



UJ 

Q 



@ Anmelder: 

Robert Bosch GmbH, 70469 Stuttgart, DE 



® Erfinder: 

Flores, Pio Torre, 70191 Stuttgart, DE; Schirmer, 
Juergen, Dr., 69124 Heidelberg, DE; Walther, 
Michael, Dr., 71696 Moglingen, DE; Huelser, Holger, 
Dr., 70329 Stuttgart, DE; Bertram, Torsten, 40547 
Dusseldorf, DE; Heckes, Marc, 47199 Duisburg, DE; 
Petersen, Joerg, 45894 Gelsenkirchen, DE 



Die f olgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

® Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug 

@ Es werden ein Verfahren und Vorrichtung zur Modellie- 
rung eines mechatronischen Systems in einem Kraftfahr- 
zeug im Rahmen eines objeklbasierten Ordnungskonzept. 
als eine Abbildung in die Unified Modeling Language be- 
schrieben. Die Elemente der CARTRONIC mit Komponen- 
ten und Hullen als ihren Klassen beziehungsweise Objek- 
ten und Auftragen (mit Riickmeldung), Abfragen (mit Hin- 
weis) und Anforderungen als ihren Kommunikationsbe- 
ziehungen sind an Hand von Beispielen zusammen mit 
den wesentlichen Regeln aus dem Gesamtregelwerk vor- 
gestellt. Fur diese Modellierungselemente wird eine Ab- 
bildungsvorschrift in UML-Konstrukte dargestellt. 
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Beschreibung 
Stand derTechnik 

5 [0001] Die Erfindung betriffl ein Verfahren und Vonichlung zur Modellierung eines mechaironischen Systems in ei- 
nem Kraftfahrzeug. 

10002] Die Forderung nach mehr Sicherheit, Wirtschaftlichkeit, Komfort sowie einer besseren Umweltvertraglichkeit 
lasst die Mechatronik im Fahrzeug zu einem immer bedeutenderen und wettbewerbsbestimmenderen Faktor werden. 
Wirtschaftliche Fahrzeugentwicklungen und die Beherrschung komplexer Systemstrukturen bei immer ktirzer werden- 
10 den Produklzyklen erzwingen durchgangige, moglichst weit automatisierte, rechnerunterstutzte Entwicklungsprozesse. 
In der Analysephase konnen auf der Basis vereinbarter, formaler Strukturierungs- und Modellierungsregeln des automo- 
bilhersteller- und zulieferemeutralen Ordnungskonzepts "Carlronic modulare", erweiterbare Architekturen fur "Funk- 
tion", "Sicberheit" und "Elcktronik" spezifiziert werden. 

[0003] Die Forderung nach mehr Sicherheit, Wirtschaftlichkeit, Komfon und einer besseren Umweltvertraglichkeit 

15 lasst die Mechatronik im Fahrzeug zu einem immer bedeutenderen und wettbewerbsbestimmenderen Faktor im Tfechno- 
logiewandel von der Mechanik uber die Elektronik zur Informationstechnik werden. Bei standig steigender Komplexitat 
der Systeme und gleichzeitig immer kiirzer werdenden Produktzyklen bleibt der Kosten- und Enlwicklungsaufwand nur 
bei Einsatz eines durchgangigen, moglichst weit automatisierten, rechnerunterstutzten sowie weitgehend parallelisierten 
Arbeits- und Entwicklungsprozesses beherrschbar. 

20 [0004] Ein Ansatz zur Losung der teilweise divergierenden Anforderungen ist die Vernetzung der bisher weitgehend 
unabhangig voneinander arbeitenden Einzelsysteme zu einem fahrzeugweiten Verbundsystem und die logische Zusam- 
menfassung von Systemkomponenten zu funktionalen Einheiten mit standardisierten Schnittstellen. Der Systemverbund 
bietet die Moglichkeit einer Kooperation und Mehrfachnutzung von Sensorik sowie Aktuatorik und somit einer Nutzbar- 
machung emergenter Funktionen. 

25 [0005] Die Vemetzung ermdglicht dariiber hinaus einen Wandel von rein funktionsorientierten Realisierungen zu Kon- 
figurationen, bei denen die Anwendungsfunktionen auf vernetzte Steuergerate abgebildet werden. AuBerdem konnen bei 
partiellen Systemausfallen dynamische Verlagerungen von Funktionen auf andere Systeme unterstutzt werden. 
[0006] Ausgehend von den logischen Funktionseinheiten mit ihren standardisierten Schnittstellen wird es ebenfalis 
moglich, Funktionen unterschiedlichen Ursprungs, verschiedener Automobilhersteller und Zulieferer, miteinander zu 

30 vernetzen. Ein Funktionslieferant muss hierbei garantieren, dass die Funktion auch bei Vferteilung auf mehrere vernetzte 
Steuergerate die geforderte Spezifikation einhalt. 

[0007] Die Entwicklung komplexer, vernetzter Systeme setzt einen systematischen Prozess mit rekursiven Phasen und 
den Einsatz rechnergestutzter Werkzeuge voraus, bei dem sowohl der Automobilhersteller als auch der Zulieferer alle 
Anforderungen und Randbedingungen an die zu entwickelnde Funktion formulieren, die vielfaltigen Interaktionen mit 

35 anderen Funktionen und der Umgebung in alien Anwendungs- und Fehlerfallen analysieren und die Funktion in ihrer 
Auswirkung auf die Sicherheit des Gesamtverbunds bewerten kann. Fur die Entwicklung von komplexen, vernetztcn Sy- 
stemen hat sich das V-Modell als Vorgehensmodell auch in der Automobilbrancheetabliert. Das V-Modell sieht vor, dass 
samtliche Aktivitaten und Ablaufe zur Funktionsentwicklung in 11 Phasen eingeordnet werden konnen (Fig. 1). 
[0008] Das V-Modell beschreibt ein Vorgehen, bei dem der Spezifikations- und Entwurfsprozess durch die Detaillie- 

40 rung und Verfeinerung charakterisiert sind und das sich als top-down- Vorgehensweise veranschaulichen lasst. Dagegen 
sind die Verifikations- und Validierungsphasen bottom -up- Vorgehenswei sen. Wesentliche Anforderung und Vorausset- 
zung fur Qualitatszertifizierungen sind hierbei detaillierte Dokumentationsunterlagen fur jede einzelne Phase. 
[0009] Urn den Forderungen nach einer wirtschaftlichen Fahrzeugentwicklung, der Beherrschung komplexer System- 
strukturen und einer adaquaten Dokumentation gerecht werden zu konnen, wurde das Ordnungskonzept "Cartronic" 

45 (siehe Bertram, X, R. Bitzer, R. Mayer und A. Volkart, 1998, CARTRONIC - An open architecture for networking the 
control systems of an automobile, Detroit/Michigan, USA, SAE 98200, 1-9) entwickelt. 

[0010] In der ersten Phase der Prozesskette, der Analyse, ermoglicht das auf objektbasierenden Grundgedanken ent- 
wickelte Ordnungskonzept die logische Zusammenfassung von Systemkomponenten zu funktionalen Einheiten mit stan- 
dardisierten, logischen Schnittstellen. Die Beschreibung der Vemetzung der bisher weitgehend unabhangig voneinander 
50 arbeitenden Einzelsysteme eines Kraftfahrzeugs zu einem fahrzeugweiten Verbundsystem stellt somit ein (Meta-)Modell 
fur eine modular erweiterbare Funktions-, Sicherheits- und Elektronikarchitektur dar. Ein wesentlicher Vorteil dieser au- 
tomobilhersteller- und zuliefemeutralen Spezifikationsmoglichkeit ist die nach kurzer Einarbeitungszeit alien am Ent- 
wicklungsprozess Beteiligten verstandliche, logische Beschreibung der Anforderungen schon zu einem sehr friihen Ent- 
wicklungszeitpunkt. 

55 [0011] Grafikbasierte Modelle unterstiitzen als wesentliche Dokumentationselemente wahrend aller Entwicklungspha- 
sen eine Kommunikation zwischen alien an der Entwicklung beteiligten Personen sowie nach Abschluss der Entwick- 
lung die Pflege und Weiterentwicklung. Erganzend zum klassischen Softwareengineering sind dabei fur mechatronische 
Systementwicklungen im Kraftfahrzeugbereich als Personengruppen zu unterstiitzen: 

[0012] Fahrzeughersteller als Benutzer/Kunden sowie Interessenten, die Informationen zur Funktionalitat des Systems 
60 benotigen, 

Ingenieure der Fachrichtungen Maschincnbau und Elcktrotechnik sowie Informatikcr als Entwicklcr der mechatroni- 
schen Komponenten auf Hersteller- und Zuliefererseite sowie diejenigen, die diese nach abgeschlossener Entwicklung 
modifizieren beziehungsweise erweitem werden und dazu Verstandnis des Gesamtsystems oder seiner Teile benotigen, 
Manager auf Entwickler- und Kundenseite, die organisatorische und wirtschaftliche Einzelheiten zur Projektkontrolle, 
65 Berechnung von Kosten und Informationen fur zukiinftige Projekte und Entwicklungen benotigen sowie nicht zuletzt 
die Fahrzeugfuhrer als spezielle Endbenutzer, die mil ausgewahlien Funktionalitaten des Systems vertraul gemacht wer- 
den miissen. 

[0013] Ein wesentlicher Schritt am Endc der Analyse- und zu Beginn der Designphase ist die Abbildung der in Cartro- 
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nic entwickelten Spezifikationsmodelle in einen informalionsiechnischen Enlwurf fur die Softwareentwicklung. Diese 
Abbildung tragi zur Erhohung der Informationsdichle und der Erweiterung des semantischen Gehalts aufgestellter Car- 
tronic-Modelle bei, definiert Teilsysteme in einer Gesamtsystemarchitektur, erhoht die Transparenz des Gesamisystems 
in Zielrichlung dessen Implementierung und schaffl wesentliche Grundlagen fur eine verieilie Entwicklung und Testbar- 
keii von mechatronischen Systemen. 5 
[0014] Vorliegend wird eine Abbildung von in CARTRONIC® erstellten Spezifikationsmodellen in eine standardi- 
sierte, objektorienuerte Darstellung vor dem Himergrund einer moglichst weitgehenden Unterstiitzung durch kommer- 
ziell verfugbare Software-Entwicklungs-Werkzeuge beschrieben. Eine dafiir erforderliche, geeignete Notation stellt der 
von der Object Management Group (OMG) international standardisierte, objektorienuerte Sprachstandard der Unified 
Modeling Language (UML) dar. 10 
[0015] Im folgenden wird eine zusammenfassende Beschreibung der Strukturelemente und formalen Strukturierungs- 
sowie Model lierungsregeln nach CARTRONIC® fur Funktionsarchitekturen gegeben. Femer wird auf einer hohen Ab- 
straktionsebene eine Funktionsarchitektur des Gesarntfahrzeugs mil einer Detaillierung fur die Komponente Antrieb vor- 
gestellt. Davon ausgehend erfolgt zunachst die Darstellung theoretischer Grundlagen der Modellierung, bevor auf die 
verwendeten Elemente der objektorientierten Notation mil UML im weiteren Verlauf dieses Abschnitts eingegangen 15 
wird. Die Vorgehensweise fiir das vorhandene Modell nach CARTRONIC® wird an einem Bei spiel aufgezeigt. 
(0016] Ein bereits in heutigen Fahrzeugen existierendes Beispiel fiir einen System verb und ist die Anlriebsschlupfrege- 
lung. Diese wird erst durch die Kommunikation des Steuergerats fur die Antriebsschlupfregelung mil dem Steuergerat 
fiir das Motormanagement zur Regelung des Antriebsmoments moglich. 

[0017] CARTRONIC® ist ein Ordnungskonzept fur alle Stcuerungs- und Regelungssysteme eines Fahrzeugs. Das 20 
Konzept enthalt modulare erweiterbare Architekturen fiir "Funktion", "Sicherheit" und "Elektronik" auf der Basis ver- 
einbarter formaler Strukturierungs- und Model lierungsregeln. 

[0018] Unter einer Architektur ist hier sowohl die Strukturierungssystematik (Regeln) zu verstehen als auch deren Um- 
setzung in eine konkrete Struktur. Die Funktionsarchitektur umfasst samtliche im Fahrzeug vorkommenden Steuerungs- 
und Regelungsaufgaben. Die Aufgaben des Systemverbunds werden logischen Komponenten zugeordnet, die Schnitt- 25 
stellen der Komponenten und ihr Zusammenwirken werden festgelegt. Die Sicherheitsarchitektur erweitert die Funkti- 
onsarchitektur urn Elemente, die einen sicheren Betrieb des Systemverbunds garantieren. SchlieBlich wird fiir die Elek- 
tronik eine Systematik angegeben, wie der Systemverbund mit bedarfsgerecht optimierten Hardwaretopologien zu reali- 
sieren ist. 

[0019] Die Elemente der Architekturen sind Komponenten und Kommunikationsbeziehungen auf der einen und Struk- 30 
turierungs- und Modellierungsregeln auf der anderen Seite. Im Rahmen der Strukturierung wird von einem System als ei- 
ner Zusammenstellung von Komponenten zu einem Ganzen gesprochen, die iiber Kommunikationsbeziehungen mitein- 
ander in Wechselwirkungen stehen. Der Begriff Komponente meint nicht zwangslaufig eine physikalische Einheit im 
Sinne eines Bauteils, sondern wird als Funktionseinheit verstanden. Bei dem Ordnungskonzept werden drei verschiedene 
Typen von Komponenten unterschieden: 35 

- Komponenten mit uberwiegend koordinierenden und verteilenden Aufgaben, 

- Komponenten mit hauptsachlich operativen und ausfuhrenden Aufgaben und 

- Komponenten, die ausschlieBlich Informationen generieren und bereitstellen. 

40 

[0020] Bei den Kommunikationsbeziehungen wird zwischen einem Auftrag (mit Ruckmeldung), einer Abfrage (mit 
Hinweis) und einer Anforderung unterschieden. Den Auftrag kennzeichnet die Pflicht zur Ausfuhrung; fur den Fall der 
Nichterfullung muss der Auftragnehmer eine Ruckmeldung an den Auftraggeber absetzen, die den Grund fur die Nichl- 
ausfuhrung beschreibt. Die Abfrage dient der BeschafFung von Informationen fur eine Auftragsausfuhrung. Fiir den Fall, 
dass eine Komponente die abgefragte Information nicht bereitstellen kann, gibt sie einen Hinweis an die fragende Kom- 45 
ponente. Eine Anforderung beschreibt einen "Wunsch", dass eine Funktion von einer anderen Komponente ausgefuhrt 
wird. An die Anforderung ist allerdings nicht die Pflicht zur Erfullung gekoppelt, was beispielsweise bei konkurrieren- 
den Anforderungen Berucksichtigung findet. Folgende Tabelle stellt die Strukturelemente zusammenfassend dar. 

50 
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STRUKTURELEMENT 


KURZBESCHREIBUNG 


5 


Komponente 


Logische Funktionseinheit . 


10 
15 


Hulle 


Von einer detaillierten Komponente 
bleibt eine Hulle, die die Kommunika- 
uiunen an cue iciiAomponencen weiter- 
leitet sowie eine „ist Teil von"- 
Beziehung ausdruckt („Sicht von auiSen 
nach innen") . 


20 
25 


System 


Ein System besteht aus mehreren Kompo- 
nenten und (Sub-) Systemen („Sicht von 
innen nach auEen") . 


30 


Auftrag (mit 
Ruckmeldung) 


Handlungsanweisung mit Pflicht zur Aus- 
fuhrung einer Funktion. 


35 


Abfrage (mit 
Hinweis) 


Ermittlung einer Information. 




Anf orderung 


„Wunsch u auf Ausfiihrung einer Funktion. 


40 


Regeln 


Regeln zu: 

□ Kommunikationsbeziehungen 

□ Modellierungsmustern 



45 



[0021] Die Strukturierungsregeln beschreiben erlaubte Kommunikationsbeziehungen innerhalb der Architektur des 
Gesamtfahrzeugs. Es werden Strukturierungsregeln unterschieden, die die Kommunikationsbeziehungen auf der glei- 
chen Abstraktionsebene und in hdhere und tiefere Ebenen unter Beriicksichtigung angegebener Randbedingungen re- 
geln. Ferner klaren die Strukturierungsregeln die Weiterleitung von Kommunikationsbeziehungen von einem System in 

50 ein anderes in dessen Detaillierung hinein. 

[0022] Die Modellierungsregeln beinhalten Muster, die Komponenten und Kommunikationsbeziehungen fur die Lo- 
sung spezicller, mehrfach vorkommender Aufgaben zusammcnfasscn. Diese Muster, zum Beispiel ein Energiemanage- 
ment, konnen dann an verschiedenen Stellen innerhalb der Struktur des Fahrzeugs wiederverwendet werden. 
[0023] Eine nach den Strukturierungs- und Modellierungsregeln entwickelte Struktur zeichnet sich durch folgende 

55 Merkmale aus: 

- vereinbarte, einheitliche Strukturierungs- und Modellierungsregeln auf alien Abstraktionsebenen, 

- hierarchische Auftragsflusse, 

- hohe Eigenverantwortung der einzelnen Komponenten, 

60 - Bedienelemente, Sensoren und Schatzer sind gleichwertige Informationsgeber und eine 

- Kapsclung, die jede Komponente fur die ubrigen Komponenten so sichtbar wie notig und so unsichtbar wie mog- 
lich dargestellt. 

[0024] Fig. 2 stellt beispielhaft die Architekturmerkmale und die erlaubten Kommunikationsbeziehungen dar. Dies 
65 sind im Einzelnen - der Einfachheit halber wird nur von Auftrag, Abfrage und Anforderung gcsprochen, gemeint ist aber 
die Beziehung, die diese jeweils ermoglichen: 

- der Auftrag moment_ga (Moment am Getricbcausgang bcreitstcllen), der von der Hulle Antricb an die Eingangs- 
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komponenle Antriebs-Koordinator weitergeleitet wird, die gleichzeilig auch Koordinator ist, 

- die Auftrage moment_ma (Moment am Motorausgang bereitstellen), stelleKraftschluss und einlegenGang (ein- 
legen eines Ganges) vom Antriebs-Koordinator an Motor, Wandler und Getriebe, 

- die Anforderung IrGang (Riickwarisgang) vom Getriebe-Bedienfeld an den Antriebs-Koordinator, 

- die Abfragen ?zustand und ?luftdruck (der Umgebung) an Getriebe und Umwelt 5 

- sowie die Abfragen ?gang (Ruckwartsgang oder nicht) und ?drehzahl an die Hulle Antrieb, die diese an die zu- 
standigen Komponenten Motor und Getriebe weiterleitet. 

[0025] Im klassischen Software-Lebenszyklus werden die streng sequentiell zu durchlaufenden Phasen Problemana- 
lyse, Systemspezifikation, Entwurf, Implemcntierung mil Komponenten-, Gesamttest und Einfuhrung sowie Betricb und to 
Pflege eines Softwaresystems unterschieden. In der Praxis ist ein solcher, streng sequentieller Entwicklungsprozess eine 
nicht einzuhaltende Idealisierung. Theoretisch klar abgrenzbare Punkte iiberlappen sich oder sind unter Umstanden un- 
terschiedlich weit vorangeschritten; gleichzeilig schreitet das Know-how auf Seiten aller am Entwicklungsprozess Be- 
teiligten mit der Systementwicklung weiter voran. Eine objektorientierte Vbrgehensweise ermoglicht ein phasenuber- 
greifendes Vorgehen mit von Anfang an hoher Wiederverwendbarkeit bereits entwickeller beziehungsweise vorhandener 15 
Anteile und Konzepte. Dies wird durch die Verwendung einer rechnerunterstiitzten, grafischen Notation wesentlich er- 
leichtert. Die in der objeklorienlierten Softwareentwicklung eingesetzten, verschiedenen, melhodischen Vbrgehenswei- 
sen beinhalten eine speziell fur die jeweilige Methode entwickelte, grafische Notation. Die UML ist hervorgegangen aus 
den drei in der industriellen Softwareentwicklung meist verwendeten Methoden, der Booch-Methode, benannt nach 
Grady Booch, der unter James Rumbaugh entwickelten Object Modeling Technique (OMT) sowie dem unter Ivar Jacob- 20 
son entwickelten Object Oriented Software Engineering (OOSE). Die UML stellt dabei keine weitere, neue, universelle 
Methode dar, sondern ein Metamodell zur Konstruktion von Modellen auf verschiedene Sichten (Fig. 3). Sie stellt eine 
grafische und erganzend tabellarische und textuelle Notation mit einheitlicher Syntax und eindeuug definierter Semantik 
dar. 

[0026] Entwickelte UML-Modelle sind von alien am Entwicklungsprozess beteiligten Personen eindeutig interpretier- 25 
bar und bieten als wesentliche Vorteile: 

- die Verwendung eines intern ationalen Standards, 

- eine moglichst herstellerunabhangige, tooluntcrstutze Vbrgehensweise, 

- eine Aufweichung der starren Einhaltung der klassischen Hintereinanderabfolge von Analyse- und Designphase 30 
bei der Softwareentwicklung ohne Aufgabe des Soft ware- Lebenszyklus-Modells als Grundlage einer ingenieurma- 
Bigen top-down- Vbrgehensweise, 

- moglichst weitgehende Unabhangigkeit von der letztendlich verwendeten Programmiersprache auf der logischen 
Ebene, 

- die Erhaltung der Konsistenz zwischen Analyse, Designentwurf und Implementierung sowie 35 

- die Moglichkeit einer gleichzeitigen bottom-up-Reversc-Engineering-Vorgehensweise. 

[0027] In der Analysephase entstehen CARTRONIC®-Modelle als eine praformal strukturierte Spezifikation, was das 
mcchatronische System leisten soli. Diese Modelle stellen eine objektbasierte Abstraktion der funktional logischen Kon- 
zepte aus den Fahrzeugsystemstrukturen dar. Durch eine geeignete Abbildung in ein weitaus machtigeres UML-Modell 40 
findet gleichzeitig der Wechsel von der Analyse- in die Design- und Entwurfsphase statt. Dabei werden Grundlagen fur 
die Gesamtarchitektur des Softwaresystems gelegt, Teilsysteme zur Reduktion beziehungsweise Beherrschbarkeit der 
Kompiexitat definiert und saubere Schnittstellen zwischen diesen spezifiziert. Die Hinzufiigung von mehr und rnehr De- 
tails fuhrt im fortschreitenden Entwurfsprozess in Richtung Implementierung. Das Ziel der Design- beziehungsweise 
Entwurfsphase besteht in der Festlegung der System komponenten, deren Aufbau und Schnittstellen mit der Definition 45 
des zugrundeliegenden logischen Datenmodells einschlieBlich der Daten- und algorithmischen Strukturen sowie deren 
Validierung. Kompiexitat ist durch Abstraktion zu bewaltigen, wobei sowohl die Einfachheit als auch Uberschaubarkeit 
des Ganzen gewahrleistet sein muss (Strukturierung im GroSen). In spateren Schritten bezieht sich die Strukturierung 
ebenso auf die Auswahl angemessener Programmbausteine bei der algorithmischen Formulierung mil dem Ziel einer 
Oplimierung der geforderten Leistungseigenschaften des Systems (Strukturierung im Kleinen). Das Ziel der Implemen- 50 
tierungsphase besteht in der Ubertragung des logischen Datenmodells, der Systemarchitektur und Algorithmen in iiber- 
sctzbaren Programmcode fur die einzelnen Steuergerate und das Kommunikationsnetzwerk im Kraftfahrzeug. 

Zeichnung 

55 

[0028] Die Erfindung ist anhand der in den Fig. 1 bis 14 dargeslellten Ausfuhrungsformen naher erlaulerl. 

Beschreibung von Ausfuhrungsbeispielen 

[0029] Im Folgenden wird die Abbildung der Cartronic-Elemente in UML-Elemente anhand des in Fig. 4 dargestellten 60 
Ausschnittcs vorgcstcllt. Wesentliche Uberlcgungcn sind hierbei, die CAKTRONIC®-Rcgeln moglichst komplett zu un- 
terstutzen, die Grundgedanken der Objektorienuerung zu wahren und dabei fur den CARTRONIC®- Model lierer ver- 
standlich genug und ausreichend transparent zu bleiben sowie alle notwendigen Informationen fiir spatere Arbeilsschritte 
aufnehmen und darstellen zu konnen. 

|0030] Fig. 4 zeigt die CARTRONIC®- Komponenten Umwelt, Antrieb, Fahrzeug- Koordinator und elektrisches Bord- 65 
netz. Zwischen diesen Komponenten bestehen folgende Kommunikationsbeziehungen: Der Fahrzeug-Koordinator be- 
fragt den Antrieb nach der aktuellen ?drehzahl beziehungsweise beauftragt den Antrieb ein moment_ga am Getriebeaus- 
gang bereitzustellen. Der Antrieb befragt den Informationsgeber Umwelt nach dem aktuellen ?lufldruck und fordcrt 
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fel_Leistung von der Komponenie elekirisches Bordnetz an. 

[0031] Klassen in der objektorientierten Terminologie sind in der Regel die Generalisierungen gleichartiger Objekte 
(Schablonen), auf hoheren Abstraktionsebenen sind Komponenten beziehungsweise Klassen seltener materielle Gegen- 
stande, sondem meislens abslrakte Gebilde oder Funktionseinheiten. Objekte (im Allgemeinen Gegenstande) sind Ex- 

5 emplare von Klassen mit Eigenschaften und Verhalten. In der objektorientierten Modellierung ist ein haufig genutzter 
Einstieg bei der Suche nach Klassen die Suche nach Substantiven,'da diese in der Sprache im Allgemeinen die Genera- 
lisierung von Objektgruppen bilden. Adjektive beschreibcn Eigenschaften und werden in der Regel als Attribute model- 
liert. Operationen wiederum bilden das Verhalten von Objeklen ab t entsprechen also den Verben. Es liegt deshalb nahe, 
die CARTRONIC®- Komponenten als UML-Klassen beziehungsweise UML-Objekte darzustellen. 

10 (0032] Uber die Stereotypen <huelle>, <informationsgeber>, <koordinator> und < operator > werden die Kom- 
ponentenklassen den oben eingefuhrten Kategorien zugeordnet. Die Komponente Umwelt aus Fig. 4 wird beispielsweise 
als Klasse mit dem Namen Umwelt und dem Stereotyp informationsgeber > dargestellt. 

[0033] Die drei CARTRONIC®-Kommunikationsarten Auftrag, Abfrage und Anforderung fordem andere Komponen- 
ten auf, "etwas zu tun" - in objeklorientierter Modellierung werden diese deshalb als Nachrichten interpretiert und mit 

15 den Stereotypen < auftrag >, < abfrage > und < anforderung > als UML-Operationen modelliert. Aus dem CARTRO- 
NIC®-Auftrag moment_ga wird die UML-Operation < auftrag > moment_ga der Klasse Antrieb, aus der CARTRO- 
NIC®- Abfrage ?drehzahl an diese Komponente die UML-Operation < abfrage > drehzahl sowie aus der CARTRO- 
NIC®- Abfrage ?luftdruck an die Komponente Umwelt die UML-Operation < abfrage > luftdruck der Klasse Umwelt. 
Bei der Darstellung in Fig. 5 symbolisiert die doppelte Linie in den Klassen Antrieb, elektrisches Bordnetz und Umwelt, 

20 dass bislang noch keine Attribute vorhanden sind. Bei der Klasse Fahrzeug-Koordinator wird auf die Darstellung even- 
tuell vorhandener Attribute oder Operationen ganz verzichtet und nur der Deklarationsbereich der Klasse abgebildet. 
Dies ergibt ein ubersichtlicheres Diagramm. CARTRONIC®-RuckmeIdungen konnen als Riickgabeparameter von 
UML-Operationen modelliert werden und sind deshalb bei der Abbildungsvorschrift nicht explizit als eigenstandige 
UML-Operationen modelliert. 

25 [0034] Die Kapselung der einzelnen Komponenten mit dem Ziel einer definierten Zugriffsregelung und -Kontrolle 
wird uber explizite UML- Schnittstellen fiir die UML-Operationen modelliert. Es wird zwischen Schnittstellen fur Auf- 
trage sowie Abfragen und Anforderungen unterschieden mit den beiden Stereotypen << interfaceAuftrag > und < inter- 
faced. Die fiir Auftrage geltenden strengeren ZugrifTsregeln nach dem "Ein-Chef-Prinzip" werden hierdurch explizit 
modelliert. Fig. 6 zeigt dies am Beispiel der Klasse < operator > Antrieb. 

30 [0035] Eine tiefer detaillierte CARTRONIC®- Komponente zeigt Fig. 7 am Beispiel der Komponente Antrieb, hier im 
Unterschied zu Fig. 2 jedoch nur mit den drei Teilkomponenten Motor, Antriebs-Koordinator und Getriebe. UML-Ag- 
gregationen driicken eine "istTeil von"-Beziehung aus und entsprechen somitexakt einer CARTRONIC®-Detail lie rung. 
UML-Kompositionen driicken als Spezialfalle von UML-Aggregationen analog zum CARTRONIC®- Verstandnis aus, 
dass Teilkomponenten ohne das Aggregat keinen Bestand haben. UML-Aggregat und UML-Komposition als logisches 

35 Ganzes delegieren (automatisch) Nachrichten, die sie erhalten, aber selber nicht ausfuhren konnen, an die entsprechende 
Teilkomponente (Analogic zur CARTROMC®-Hulleneigenschaft). Fig. 8 zeigt die teilweise detaillierte UML-Klasse 
<huelle> Antrieb als UML-Komposition der UML-Klassen Motor, Antriebs-Koordinator und Getriebe. 
[0036] GroBe komplexe CARTRONIC®-Komponenten auf hohem abstraktem Niveau konnen analog zur Modellie- 
rung iiber UML-Klassen auch als UML-Subsystcme abgebildet werden. UML-Subsysteme sind cine Sondcrform von 

40 UML-Paketen, die Schnittstellen besitzen diirfen und deshalb geeignel sind, eine sinnvolle Kapselung und Strukturabbil- 
dung im GroBen zu gewahrleisten. Die separaten SchnitLstellen fiir Auftrage beziehungsweise Abfragen und Anforderun- 
gen bleiben dabei ebenso erhalten, wie analog die im Folgenden vorgestellten Vorgehensschritte. Verbindungen in Form 
einer Aggregation oder Komposition zwischen dem Subsystem und darin enthaltenen Modellelementen ennbglichen die 
Weiterleitung von Nachrichten von den Subsystem-Schnittstellen direkt zu den entsprechenden Komponenten. Wie in 

45 Fig. 9 gezeigt, kann eine Schnittstelle, hier < interfaceAuftrag > IA_Antrieb, direkt durch die Schnittstelle cines inter- 
nen Elements, hier < interfaceAuftrag > IA_Antriebs-Koordinator, bereitgestellt werden. 

[0037] Die standige Weiterentwicklung der CARTRONIC®-Modelle erfordert Veranderungs- und Austauschmoglich- 
keiten von Komponenten. Neben der im vorhergehenden Teilabschnitt beschriebenen Abbildung einzelner CARTRO- 
NIC®-Elemente in die UML miissen die Schritte und Vorgange im fortlaufenden Entwicklungsprozess unterstiitzt wer- 

50 den. In der Praxis treten hierbei Mischformen der nachfolgend unterschiedenen Vorgehensschritte auf. Diese setzen sich 
zusammen aus der Detaillierung, der Abstraku'on, dem Ersetzen sowie dem Loschen von Elementen. 
[0038] Bei der Detaillierung einer CARTRONIC®-Komponente entsteht nach dem CARTRONIC®-Rcgelwerk eine 
Hulle ohne eigene, logische Funktionen; alle bereits bekannten, existierenden Funktionalitaten werden auf die entstehen- 
den Teilkomponenten verteilt. Die Kapselung beziehungsweise die SchnitLstellen der zu detaillierenden Komponente 

55 miissen vollstandig in der Hulle erhalten bleiben, um das Verhalten nach auBen nicht zu verandcrn. Dies sind im Beispiel 
in Fig. 6 die Operationen moment_ga und drehzahl der Klasse Antrieb. Fig. 10 zeigt die neue UML-Klasse nach der De- 
taillierung. Detailliert ist hier in die Klassen Motor, Antriebs-Koordinator und Getriebe sowie zusatzliche Operationen 
< auftrag > momenl_ma, < anforderung > rGang und < auftrag > einlegenGang. Zu beachten ist die Darstellung der 
Klasse Antrieb mit dem nunmehr leeren Operationsbereich sowie der Anderung des Stereotyps in < huelle >. Die < ab- 

60 frage> luftdruck der Komponente Motor aus der Komponente Antrieb heraus an den <informationsgeber> Umwelt 
wird modelliert iiber eine Beziehung zwischen dicsen beiden Komponenten in Form einer Assoziation - beide miissen 
sich kennen - sowie eine Abhangigkeit von Motor an die entsprechende Schnittstelle von Umwelt, Dies gilt analog fur 
alle CARTRONIC®-Kommunikationsbeziehungen. Die explizite Modellierung aller Beziehungen der UML-Klassen un- 
tereinander fuhrt automatisch zu einem vollstandigen Uberblick iiber alle Zugriffe auf jede einzelne Schnittstelle. 

65 (0039] A bstraktions vorgange sind notwendig und sinnvoll fiir eine kompakte und iibersichtlichc Darstellung struktu- 
rierter, komplexer Komponentenstrukturen durch ihre Hiillenkoinponenle und Schnittstellen. Bei dem \forgang der Ab- 
straktion diirfen keine Informationen aus der detail lierten Darstellung verloren gehen, und Abhangigkeiten zwischen ver- 
schicdenen Komponenten miissen moglichst ohne Hinzufugung weiterer Information abgebildet werden. Bei der Ab- 
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straklion vom delailiierten UML-Aggregat Anirieb in Abb. 10 bleibt im Unlerschied zu der in Fig. 6 dargesiellten Kom- 
ponente Antrieb eine "leere" Klasse (Fig. 1 1 ). Hierbei ergibt sich aber das Problem der Nicht-Sichtbarkeit der Beziehung 
zwischen einer Teilkomponente von Anirieb und Umwelt. Deshalb erfordert das UML-Modell zusaizlich zur CARTRO- 
NIC®-Funklionsarchileklur eine kiinstlich geselzte Assozialion und Abhangigkeit zwischen den Komponenten Anirieb 
und Umwelt. Bei Einsaiz eines Modellierungslools kann diese Problematik beispielsweise durch enlsprechende Zusatz- 5 
allribule beriicksichtigl werden. 

(0040] Die einfachste Art des Austauschens von Elementen isl ein Austausch mil glcicher Funktionalitat, bei dcm Mo- 
difikationen nur intern in einer Komponente ohne eine nach auBen sichtbare Veranderung von Namen, Schnittstellen 
oder Beziehungen vorgenommen werden (Fig. 12). 

[0041] Ein Austausch mit erweiterter Funktionalitat licgt vor, wenn eine Komponente den Namen, vorhandene Bczie- to 
hungen und ihre alte Funkuonalitat behalt, jedoch urn neue Funktionalitat und damit neue Schnittstellenoperaiionen er- 
weitert wird ( Fig. 1 3). 

[0042] Werden bei einem Austausch innere Elcmente einer Komponente so modifiziert, dass neue Beziehungen zu an- 
deren Komponenten erforderlich werden, handelt es sich urn einen Austausch mit veranderten Beziehungen. Dies isl zum 
Beispiel der Fall bei zusaizlich abgefragter Information. Der Komponentenname und die Schnittstellen bleiben hierbei is 
unverandert (Fig. 14). 

[0043] Beim Austauschen mit wegfallender Funktionalitat entfallen einzelne Funkuonen beziehungsweise Operalio- 
nen in den Schnittstellen. Vor dem eigentlichen Loschvorgang muss deshalb eine (automatisierte) Konsistenzpriifung zur 
Sicherstellung erfolgen, dass keine weitere Komponente des Gesamtmodells die zu loschenden Elemente noch verwen- 
det. 

[0044] Das Loschen einer Komponente kann als Sonderform des Austauschens mit wegfallender Funktionalitat be- 
trachtet werden. Hierbei wird eine vorhandene Klasse in eine "leere" uberfuhrt durch iterativen Wegfall ihrer Operatio- 
nen. 

[0045] Es wird also ein Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraft- 
fahrzeug im Rahmen eines objektbasierten Ordnungskonzepts als eine Abbildung in die Unified Modeling Language be- 25 
schrieben. Diese stellt ein wesentliches Bindeglied zwischen der Analyse- und Design- beziehungsweise Entwurfsphase 
im objektorientierten Softwareentwicklungsprozess dar. Die Elemente der CARTRONIC® mil Komponenten und Hullen 
als ihren Klassen beziehungsweise Objekten und Auftragen (mit Ruckmeldung), Abfragen (mit Hinweis) und Anforde- 
rungen als ihren Kommunikationsbeziehungen sind an Hand von Beispielen zusammen mit den wesentlichen Regeln aus 
dem Gesamtregelwerk vorgestellt. Fiir diese Modellierungselemente wird eine Abbildungsvorschrift in UML-Kon- 30 
strukte dargestellt. CARTRONIC®-Komponenten einschlieBlich -Hullen werden als UML-KIassen beziehungsweise - 
Objekte mit den Stereotypen < koordinator>, < operator >, < informationsgeber> und <huelle> abgebildet. Die 
CARTRONIC®-Kornmunikationsbeziehungen Abfrage und Anforderung werden als UML-Operationen mit den Stereo- 
typen < abfrage > und < anforderung > in Schnittstellen mit dem Stereotyp < interface > bereitgestellt, alle Auftrags- 
operationen werden durch den Stereotypen <auftrag> in Schnittstellen mit Stereotyp < interfaceAuftrag > gekenn- 35 
zeichnct. In eine detaillierte Komponente eingehende Nachrichten werden automatisch uber Kompositionsbeziehungen 
an die jeweils zustandigen Teilkomponenten delegiert. Fur nicht hierarchische Kommunikationsbeziehungen zwischen 
Auftraggeber und Beauftragtem wird zwischen diesen eine Assoziation und von dem Auftraggeber zu der Schnittstelle 
des Beauftragten eine Abhangigkcitsbeziehung modelliert. Die Kapselung von Komponenten wird somit uber die beiden 
separalen Schnittstellen, die Komposilion als implizite Zugehorigkeilsbeziehung und die Darstellung der Abhangigkei- 40 
ten gewahrleistet. Fiir die im Entwicklungsprozess auflretenden Vorgange Detaillierung, Abstraktion, Austausch und Lo- 
schen von Komponenten werden Vorgehensweisen fiir den Einsatz eines kommerziell verfugbaren UML-Softwareent- 
wicklungswerkzeuges aufgezeigt. 



Patentanspriiche 45 

1. Verfahren zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug, wobei das mechatronische 
System aus mehreren Komponenten besteht, zwischen denen vorgegebene Kommunikationsbeziehungen bestehen, 
dadurch gekennzeiehnet, daB die Komponenten und Kommunikationsbeziehungen zwischen den Komponenten 

im Rahmen einer objektorientierten Modellierungssprache dargestellt werden. 50 

2. Verfahren nach Anspruch 1, dadurch gekennzeiehnet, dass die objektorientierte Modellierungssprache die uni- 
fied modeling language ist. 

3. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeiehnet, daB auf der Basis der dargestell- 
ten Komponenten und Beziehungen das Softwaredesign erstellbar ist. 

4. Verfahren zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug, wobei das mechatronische 55 
System in mehrere Komponenten zwischen denen vorgegebene Kommunikationsbeziehungen wie Abfrage, Auf- 
forderung und Auflrag bestehen, gegliedert ist, dadurch gekennzeiehnet, daB eine Abbildungsvorschrift vorgesehen 

ist, mit der die Komponenten und Beziehungen des Systems in Konstrukte einer objektorientierten Modellierungs- 
sprache, vorzugsweise der UML-Sprache, umgesetzt werden. 

5. Verfahren nach Anspruch 4, dadurch gekennzeiehnet, dass die Abbildungsvorschrift darin besteht, dass die 60 
Komponenten einschlieBlich -Hullen als UML-KIassen beziehungsweise -Objekte mit den Stereotypen < koordi- 
nator>, < operators, <*informationsgeber> und <huelle> abgebildet werden, die Kommunikationsbeziehun- 
gen Abfrage und Anforderung als UML-Operationen mit den Stereotypen < abfrage > und < anforderung > in 
Schnittstellen mil dem Stereotyp < interface > bereitgestellt werden und alle Auftragsoperationen durch den Ste- 
reotypen «auftrag> in Schnittstellen mit Stereotyp « interfaceAuftrag > gekennzeiehnet werden. 65 

6. Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug, welches aus mehreren 
Komponenten besteht, zwischen denen vorgegebene Kommunikationsbeziehungen bestehen, dadurch gekenn- 
zeiehnet, dass die Komponenten und Kommunikationsbeziehungen zwischen den Komponenten im Rahmen einer 
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objektorientierten Soflwaresprache dargestellt sind. 

7. Vorrichtung zur Modellienjng eines mechatronischen Systems in einem Kraftfahrzeug, welches aus mehreren 
KomponenLen besteht, zwischen denen vorgegebene Kommunikationsbeziehungen bestehen, gekennzeichnetdurch 
eine Abbildungsvorschrift, mil der die KomponenLen und Beziehungen des Systems in Konstrukte einer objektori- 
entierten Modellierungssprache, vorzugsweise der UML-Sprache, umgesetzt werden. 
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Abstract of DE10015114 

The invention relates to a method and a device 
for modelling a mechatronic system in a motor 
vehicle according to an object-based 
architecture, whereby said system is represented 
in the unified modelling language. The elements 
of the CARTRONIC(R) which comprise 
components and sleeves as the classes thereof 
or objects and orders (with feedback), inquiries 
(with hints) and requests as the communications 
relations thereof are provided by means of 
examples and together with the essential rules of 
the entire catalogue of rules. A representation 
rule for said modelling elements is provided in 
UML constructs. 
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Abstract of DE1 9639424 

The design system uses a combined model defining both the ind. process characteristics of the plant and 
the control engineering characteristics. The model is used for control and/or regulation and/or simulation 
of the plant operation for failure analysis. Pref. the technological specifications are selected and a 
corresponding technical design solution is provided, using a file (11) of component types, with a 
simulation process used for validation. 
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) Entwurf s verfahren fOr die Anlagentechnik und rechnerge- 
stutztes Projektierungssystem zur Verwendung bei diesem 
Verfahren. 

Insbesondere fOr die Automatfsierung von Industrieaniagen 
!8Bt sfch die Technologle der Anlage durch ProzeBtechnik 
elnerselts sowie durch Leittechnik sndererseits beschreiben. 
GemaS der Erfindung werden aus Modellen des Prozesses 
und der Leittechnik verfahrenslechnische Objekte gebildet, 
die in einem rechnergestOtzten Projektierungssystem verar- 
beitet warden, woraus Ineinander verzahnte Modelle mit 
Steuerung und/oder Regelung und/oder Simulation ein- 
schlieBIich Stdrungsanaiyse erzeugt werden. Beim zugehori- 
gen Projektierungssystem erfolgt mit einem Rechner (10) 
gleichermaSen ein Zugriff auf eine Komponentenbibliothek 
(11) von verfahrenstechnischen Elementen und auf eine 
Beschreibung (12) der Elemente der konkreten Anlage aus 
der Sicht etnas verfahrenstechnischen Technologen. 
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Beschreibung 

Entwurfsverfahren fur die Anlagentechnik und rech- 
nergestOtztes Projektierungssystem zur Verwendung 
bei diesem Verfahren 

Die Erfindung bezieht sich auf ein Entwurfsverfahren 
fur die Anlagentechnik, insbesondere zur Verwendung 
bei der Automatisierung von Industrieanlagen, wobei 
die Technologie der Anlage durch ProzeBtechnik einer- 
seits und durch Leittechnik andererseits beschrieben 
wird. Daneben bezieht sich die Erfindung auch auf ein 
rechnergestutztes Projektierungssystem zur Verwen- 
dung bei diesem Verfahren, enthaltend einen Digital- 
rechner mit Zentraleinheit, Arbeits-, Programm- und 
Datenspeichern und mit Mitteln zur Codegenerierung. 

Bei der Automatisierung von Industrieanlagen wird 
bisher im allgemeinen von einer vorgegebenen ProzeB- 
technik ausgegangen, zu welcher eine zugehorige Leit- 
technik entwickelt werden muB, was iiblicherweise von 
einem Elektrotechniker als Projekteur durchgefuhrt 
wird. 

Eine wesentliche Aufgabe bei der Konzeption der 
Leittechnik einer Anlage ist zunachst einmal eine Auf- 
gabenklarung, die zusammen mit dem spateren Betrei- 
ber der Anlage erfolgen muB. Wesentlich ist dabei die 
Erstellung einer externen Spezifikation, welche die An- 
forderungen an die zu projektierende Leittechnik be- 
schreibt Ublich ist heutzutage, daB dazu ein Technologe 
mit dem Projekteur zusammenarbeitet. Als Ergebnis 
entstehen dabei Funktionsplane, d. h. eine Beschreibung 
der zu I6senden Projektierungsaufgabe aus der Sicht 
des Elektrotechnikers. 

Bei der Umsetzung solcher Funktionsplane in eine 
weiterbearbeitbare softwaremaBige Losung gibt es je- 
doch haufig Probleme, weil Diskrepanzen zwischen ex- 
terner Spezifikation und der fertigen Losung entstehen. 

Aufgabe der Erfindung ist es daher, die bisher be- 
kannten Entwurfsverfahren fur die Anlagentechnik zu 
verbessern und zugehdrige Werkzeuge zu schaffen. 

Die Aufgabe wird erfindungsgemaB durch folgende 
MaBnahmengelost: 

— Es werden aus Modellen der Prozesse und der 
Leittechnik verfahrenstechnische Objekte gebildet, 

— die verfahrenstechnischen Objekte werden in 
einem rechnergestUtzten Projektierungssystem 
verarbeitet, 

— daraus werden ineinander verzahnte Modelle 
bestehend aus Steuerung und/oder Regelung und/ 
oder Simulation einschlieBlich Storungsanalyse er- 
zeugt 

Bei der Erfindung ist das Verfahrensergebnis als Soft- 
ware und/oder als Hardware ausfuhrbar. Wesentlich ist, 
daB zur Beschreibung der Anlage jeweils rechnerge- 
stlltzt die Modelle des Prozesses und der Leittechnik in 
einem Anlagenmodell zusammengefaBt und daraus au- 
tomatisiert ineinander verzahnte Modelle erstellt wer- 
den. 

Im Rahmen der Erfindung werden jeweils anwen- 
dungsneutrale Beschreibungsmittel gewahlt Insbeson- 
dere kommt es darauf an, die Spezifikation so technoio- 
gienah zu wahlen, daB die verfahrenstechnische Losung 
erkennbar ist, wobei die Funktionsbeschreibung der 
Strukturbeschreibung untergeordnet ist Solche Spezifi- 
kau'onen konnen dann formal analysiert und simulativ 
validiert werden. Damit ist es mdglich, jnmittelbar aus 
der Spezifikation einen Code fur das im Rahmen des 
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Projekuerungssystem zu verwendende Automatisie- 
rungsgerat zu erzeugea 

Besonders vorteilhaft ist beim erfindungsgemaBen 
Verfahren, daB die bei der Projektierung entwickelten 
5 Modelle anschlieBend unmittelbar bei der Anlagenreali- 
sierung verwendet werden. Im Ergebnis ergibt sich da- 
durch ein wesentliches EinsparpotentiaL 

Bei einem geeigneten Projektierungssystem zur Ver- 
wendung bei dem erfindungsgemiBen Entwurfsverfah- 
io ren erfolgt mit dem Digitalrechner gleichermaBen ein 
Zugriff auf eine Bibliothek von Komponententypen und 
auf eine Beschreibung der Koraponenten der konkreten 
Anlage. Entscheidend ist dabei, daB fur die Benutzung 
der Komponentenbibliothek die Beschreibung aus der 
is Sicht des verfahrenstechnischen Technologen defmiert 
ist Vorzugsweise hat die Komponentenbibliothek eine 
branchenspezifische Auslegung. 

Mit dem erfindungsgemaBen Projektierungssystem 
ist also ein Werkzeug geschaffen, bei dem die Kompo- 
20 nententypen aus der Sicht des Technologen defmiert 
sind und ein unmittelbarer Bezug zur ProzeBtechnik 
besteht 

Die Erfindung wurde beispielhaf t im Rahmen der Pa- 
piertechnologie untersucht und es wurde ein Demon- 
25 strator fur eine Altpapieraufbereitung erstellt Daruber 
hinaus konnte gezeigt werden, daB die erzielten Ergeb- 
nisse auf andere Bereiche der Anlagentechnik verallge- 
meinerbar sind. 
Weitere Einzelheiten und Vorteile der Erfindung er- 
30 geben sich aus der nachfolgenden Figurenbeschreibung 
von Ausfuhrungsbeispielen anhand der Zeichnung. Es 
zeigen jeweils als Prinzipdarstellung 
Fig. 1 das neue Entwurfsverfahren, 
Fig. 2 das zugeh6rige Projektierungssystem, 
35 Fig. 3 der hierarchische Aufbau der dabei als Kompo- 
nententypen verwendeten verfahrenstechnischen Ele- 
ments 

Fig. 4 die Beschreibung einer Anlage mit dem Projek- 
tierungssystem, 

40 Fig. 5 die dabei verwendete Methode zur automati- 
schen Codegenerierung und 

Fig. 6 das Vorgehen bei der Fehlerdiagnose. 
Unter einer Anlage versteht man im allgemeinen die 
Gesamtheit der Ausrustungen eines Betriebs, die zur 
45 Produktion, zur Fertigung, zur Energieerzeugung und/ 
oder zu Fdrder- bzw. Transportzwecken erforderlich 
sind. Im Nachfolgenden werden unter dem Begriff w In- 
dustrieanlage" Qberwiegend GroBanlagen wie beispiels- 
weise Kraftwerke, Miillverbrennungsanlagen oder auch 
so Papierfabriken verstanden. 

Zur Erstellung einer Anlage mussen unterschiedliche 
Partner zusammenwirken: Dies ist einmal der Betreiber, 
dessen Ziel es ist, durch das Anbieten von Dienstleistun- 
gen bzw. Produkten ein Ergebnis zu erzielen. Dazu 
55 orientiert er sich an den BedQrfnissen des Marktes. Er 
formuhert seine Zieie mit Hilfe von Begriffen wie 
Durchsatz, Kosten, Qualitat und/oder Produktivitat 

Vom Betreiber der kunftigen Anlage nehmen ubli- 
cherweise Technologen die Anforderungen entgegen 
6o und setzen sie urn in einen Entwurf fur eine Anlagen- 
konfiguration. Technologen benotigen dabei Wissen 
uber notwendige Verfahrensschritte, da sie fur die Aus- 
legung der verschiedenen Anlagenteile zustandig sind 
Als Ergebnis erzeugen die Technologen ein Technolo- 
65 gieschema, in dem die einzelnen Maschinen, Sensoren, 
Stellglieder, aber auch Material-, Wirk- und Informa- 
tionsfliisse festgelegt sind. 
Da fur gewisse Verfahrensschritte der Anlage Einzel- 
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Idsungen in Form von Maschinen und Ausrilstungen, die Anlage uber Parameter und Wechselbeziehungen ein- 

von Komponentenlieferanten angeboten werden, be- gestellt Wichtig ist, daB die Koraponententypen aus der 

reitsvorhandensind,isteszweckma8ig,zwischenLiefe- Sicht des Technologen definiert wurden, so daB nun- 

ranten far die ProzeBtechnik und Lieferanten fur die mehr ein unmittelbarer Bezug zur ProzeStechnik mog- 
Leittechnik zu unterscheiden. Oblicherweise erstellen 5 Hen ist Fur die einzelnen Komponententypen wird die 

Systemintegratoren aus den einzelnen Komponenten Struktur gemeinsam fur aUe Anteile der Entwurfsver- 

der Komponentenlieferanten die komplette Anlage. fahren und das Verhalten unter den Aspekten Steue- 

Wesentlich fflr ein erfolgreiches Entwurfsverfahren rung und Regelung, Prozefisimulation und Stdrungsana- 

sowie die weitere Erstellung bei der Anlagentechnik ist lyse spezifiziert Die Komponenten der konkreten Anla- 
die technologische Kompetenz, welche fur die Leittech- 10 ge erh&lt man daraus durch Instanziierung der Kompo- 

nik einerseits und fur die ProzeBtechnik andererseits nententypen. 

maBgebend ist Die Leittechnik umfaBt dabei alle Ein- In Fig. 2 kennzeichnet 10 einen ublichen Digitalrech- 

richtungen, die zum automatischen Betrieb der Anlage ner mit Zentraleinheit 101, Eingabeeinheit 102 und Mo- 

notwendig sind. Dazu gehoren beispielsweise unter an- nitor 103. Die Zentraleinheit 101 beinhaitet u. a. 
derem die Aktoren und Sensoren, die Hard- und Soft- 15 Arbeits-, Programm- und Datenspeicher, die nicht im 

ware der Automatisierungsebene und die Koraponen- einzelnen dargestellt sind. Wesentlich ist im vorliegen- 

ten der Leit- und FQhrungstechnik der Anlage. Die ei- den Zusammenhang, daB im Datenspeicher eine Kom- 

gentliche ProzeBtechnik wird dagegen durch Aggrega- ponententypbibliothek 11 von verfahrenstechnischen 

te, Pumpen, Ventile a dgL beschrieben. Elementen vorhanden ist, die sich zu komplexeren Ob- 

In Fig. 1 geht der Block 1 von der bekannten Techno* 20 jekten kombinieren lassen. Letzteres ist in Fig. 2 durch 

logie einer zu projektierenden Anlage aus. Fur die Anla- den separaten Block 1 1, der mit der Zentraleinheit 101 

gentechnik ist dabei sowohl die Leittechnik als auch die bzw. dem Monitor 103 verbunden ist, angedeutet Durch 

ProzeBtechnik von Bedeutung, welche miteinander in Instanziierung einzelner Elemente lassen sich im Be- 

Wechselwirkung stehen. Anhand von Block 2 wird die reich tV solche Objekte als Modelle bilden und unmit- 

zugehdrige Beschreibung verdeutlicht: Das Anlagen- 25 telbar auf dem Monitor 103 darstellen. 

modell besteht dabei einerseits aus einem Modell der In Fig. 3 ist verdeutlicht, daB die Komponentenbi- 

Leittechnik und andererseits aus einem Modell des Pro- bliothek 12 einen hierarchischen Aufbau hat Beispiels- 

zesses, welche zumindest einmal voneinander zu tren- weise sind in einer untersten Ebene 111 Sensoren und 

nen sind. Im Block 3 sind die ausfuhrbaren Modelle Aktoren vorhanden und in der nachsten Ebene 112 Ven- 

eingetragen, die im einzelnen miteinander verzahnt sind 30 tile und Motoren als sog. Typicals. In den daruberliegen- 

Dabei verdeutlicht die Verzahnung, daB nunmehr erst- den Ebenen 113 bis 116 folgen komplexere Komponen- 

malig die bisher Ublichen Abgrenzungen aufgehoben ten sowie Teilanlagen, Anlagen und die Fabrik als kom- 

sind. Insbesondere die Teilmodelle greifen jeweils auf plette Industrieanlage. Solche Objekte konnen vom Be- 

solche Informationen, die in anderen Teilmodellen be- nutzer unmittelbar abgeruf en werden. 

reits beschrieben sind, zurflck. Eine doppelte Beschrei- 35 In Fig. 4 stellt Block 11 eine solche Komponentenbi- 

bung unterbleibt also, was insbesondere bei einer im bliothek dar, die branchenspezifisch strukturiert ist, und 

allgemeinen immer notwendigen Stdrungsanalyse Vor- Block 12 eine zugehorige zu projektierende Industrie- 

teile hat. anlage. Die Beschreibung der konkreten Anlage 12 ent- 

GemSfl Fig. 1 sind dem ProzeBmodell entsprechende . sprechend der Vorgehensweise gemaB Fig. 1 erfolgt 

Einheiten zur Steuerung und/oder Regelung und/oder 40 durch Instanziierung der Komponenten aus der Kom- 

Simulation einerseits sowie zur Storungs analyse ande- ponentenbibliothek 11. Durch Hinzufugen der Parame- 

rerseits zugeordnet SchlieBlich umfaBt der Block 4 die terwerte mit entsprechenden Wechselbeziehungen der 

sphere Realisierung der Anlage mit entsprechender Anlage 12 laBt sich die Beschreibung selbst realisieren. 

Stdrungsanalyse. Durch die Berucksichtigung der Anlagenstruktur wird 

Bei der Vorgehensweise entsprechend Fig. 1 ist die 45 dabei fur die einzelnen Anteile des Entwurfsverfahrens 

Basis des Entwurfsverfahrens eine technologiennahe das globale Verhalten der Anlage aus den lokalen Be- 

Beschreibung der Struktur einer Anlage und deren schreibungen automatisch konstruiert 

Funktionsweise. Durch die Kombination von Techniken Die Codegenerierung ftir die Steuerung und Rege- 

zum Entwurf von Steuerungen und Regeiungen, zur Si- lung einer zu projektierenden Anlage kann entweder 

mulation und zur Diagnose wird ein aus fuhrbares Anla- 50 unmittelbar auf der Beschreibung der Anlage aufsetzen 

genmodell erstellt, das den Spezifikationen entspricht oder alternativ auf dem ausfuhrbaren Modell der Steue- 

Die Spezifikation fur das Anlagenmodell kann an- rung und Regelung basieren. GemaB letzterer Alternati- 

schlieBend im einzelnen formal analysiert und simulativ ve ist es dafur erforderlich, daB die Steuerungs- und 

validiert werden, d. h. durch Simulationsrechnungen be- Regelungsvorgange explizit deterministisch beschrie- 

statigt werden. Die Simulation erfolgt mit graphischer 55 ben sind. Es wird in diesem Fall von einer alternativen 

Unterstiitzung, urn gemeinsam dem Technologen die Codegenerierung gesprochen. 

Aufgabenklarung zu verdeutlichen und ggfs. die Spezifi- Die alternative Codegenerierung nutzt gewisse Pha- 

kation zu modifizieren. Die validierte Spezifikation wird sen eines bekannten CSL-Compilers, in dem sie nicht 

dahingehend genutzt, daB daraus weitestgehend auto- auf der bekannten Sprache CSL, sondern auf der Spra- 

matisch ein Code ftir Automatisierungssysteme erzeugt 60 che SCSL auf setzt Es wird dabei nicht der voile Umfang 

werden kann, was im einzelnen in der europSischen Pa- der Sprache SCSL von der alternativen Codegenerie- 

tentveraffentlichung EP-A-0 671 027 fur spezifische An- rung berucksichtigt Hierzu ist in Fig. 5 ein sogenannter 

wendungszwecke bei der Bahntechnik be-schrieben ist CSL-Compiler 30 dargestellt, dem aus Fig. 1 bis Fig. 4 

Ein System zur Verwendung bei einer Vorgehenswei- die Blocke der Komponentenbibliothek 1 1 und des kon- 

se gem&B Fig. 1 beinhaitet eine technologiennahe Be- 65 kreten Anlagenaufbaus 12 zugeordnet sind. Der CSL- 

schreibung der betreffenden Anlage. Dabei setzt sich Compiler 30 besteht aus den Einheiten 31 ftir die Instan- 

die konkrete Anlage zusammen aus Objekten der Kom- tiierung, 32 fur die sogenannte Expansion, 33 fur die 

ponentenbibliothek und wird so auf die abzubildende Codierung und 34 fOr das Gleichungslosen, mit denen 
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ein Automat 40 generiert wird. Bei der alternativen Co- 
degenerierung wird an der Einheit 32 abgegriffen und 
flber die SCSL-Sprache in der Einheit 36 zur Codegene- 
rierung der tatsachliche Code realisiert. 

Bei der Sprache SCSL wird also vom CSL-Compiler 5 
30 ein Zwischenergebnis ausgenutzt, das nach der Ex- 
pansion erzeugt wird AJs Zielsprache wird bei der Co- 
degenerierung ein zielmaschinenunabhangiger Zwi- 
schencode erzeugt, der der Norm IEEC 1131-3 ent- 
spricht 10 

Das an den Prinzipschaubildern gemaB Fig. 1 und 3 
erlauterte Verfahren geht aus von Verfahren zur Be- 
schreibung und Analyse zustandsahnlicher Systeme. 
Dieses Verfahren ermoglicht die Konstruktion der 
Steuerung und Regelung einer hierarchisch aufgebau- 15 
ten Anlage aus der Strukturbeschreibung und der Be- 
schreibung Iokaler Steuerungs- und Regelungsvorgan- 
ge. Damit werden die Inkonsistenzen zwischen den un- 
terschiediichen lokalen Anforderungen automatisch 
aufgedeckt Die Regelungsaufgaben sind dagegen weit- 20 
gehend entkoppelt, so dafi eine Trennung in analoge 
und diskrete Zusammenhange moglich ist 

Fiir eine simulative Validation der Steuerung- und 
Regelungsvorgange wird das Verhalten von ProzeB, 
Sensorik und Aktorik in Form eines Simuiationsmodel- 25 
les beschrieben. Das Gesamtverhalten der Anlage wird 
auch hier durch eine Kombination iokaler Modelle un- 
ter Berucksichtigung der Strukturbeschreibung kon- 
struiert Fur die Validation des Diagnoseanteils werden 
zusatziich mtfgliche Fehlerfalle von Komponenten mo- 30 
delliert 

Zur Analyse von Storungen, die durch Anlagenfehler 
hervorgerufen werden, lassen sich Verfahren der mo- 
dellbasierten Diagnose verwenden. Daftir wird die 
Kombination Iokaler Modelle des Normal- und Fehlver- 35 
haltens von Komponenten entsprechend der Anlagen- 
struktur zur Erkennung und Identifikation von Fehlern 
benutzt. FGr eine engere Integration von Steuerungs- 
entwurf und Diagnosetechnik sind Konzepte zur Feh- 
lererkennung durch die Steuerung und Analyse des 40 
Steuerungszustandes bekannt. 

Aus Fig. 6 ergibt sich im wesentlichen selbsterklaren- 
der Weise, wie die Diagnose durch Finden und Analyse 
von Diskrepanzen erfolgen kann. Dabei wird davon aus- 
gegangen, daB die Erkennung des Zielverhaltens eines 45 
technischen Systems die Bestimmung plausibler EriSu- 
terungen fur das beobachtete Fehlverhalten, d h. die 
Diagnose, far die Wiederherstellung seiner urspriingli- 
chen Funktion entscheidend ist Die Diagnose setzt da- 
bei das Wissen uber das normale erwartete Verhalten 50 
des Systems voraus. 

Bei der modellbasierten Diagnose gemaB Fig. 4 wird 
von einem expliziten Modell des zu diagnostizierenden 
Systems ausgegangen. Dies Modell umfaBt eine Be- 
schreibung der Struktur des Systems, d h. der Kompo- 55 
nenten und ihrer Verbindungen, sowie lokale, d h. kon- 
textfreie Beschreibungen des Verhaltens einzelner 
Komponenten. Es werden im wesentlichen qualitative 
Modelle verwendet, urn den ModellierungsprozeB zu 
vereinfachen. 60 

Auf der Basis einer solchen Systembeschreibung wird 
unter der Annahme, daB jede Komponente sich korrekt 
verhalt, das Verhalten des Gesamtsystems vorhergesagt 
und dabei protokolliert, von welchen Korrektheitsan- 
nahmen bestimmte Aspekte dieses Verhaltens abhan- 65 
gen. Treten Diskrepanzen zwischen vorhergesagtem 
und beobachtetem Verhalten auf, werden die protokol- 
lierten Abhangigkeiten verwendet, um die Mengen von 



Korrekturannahmen zu identifizieren, die fur die Dis- 
krepanzen verantwortlich ist Diese Mengen von inkon- 
sistenen Annahmen werden auch Konflikte genannt 
Um alle Konflikte aufzul6sen, muB eine Diagnose min- 
destens eine Annahme aus jedem Konflikt zuriickzie- 
hen. Auf diese Weise erhalt man im allgemeinen mehre- 
re Diagnosen, die sich durch genauere Modelle und zu- 
satzliche Beobachtungen weiter modifizieren lassen. 

Patentanspruche 

1. Entwurfsverfahren fur die Anlagentechnik, insbe- 
sondere zur Verwendung bei der Automatisierung 
von Industrieanlagen, wobei die Technologie der 
Anlage durch ProzeBtechnik einerseits und durch 
Leittechnik andererseits beschrieben wird,gekenn- 
zeichnet durch folgende MaBnahmen: 

— Es werden aus Modellen der Prozesse und 
der Leittechnik verfahrenstechnische Objekte 
gebildet, 

— die verfahrenstechnischen Objekte werden 
in einem rechnergestutztem Projektiemngssy- 
stem verarbeitet, 

— daraus werden ineinander verzahnte Mo- 
delle bestehend aus Steuerung und/oder Rege- 
lung und/oder Simulation einschlieBlich Sto- 
rungsanalyse erzeugt 

2. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, daB das Verfahrensergebnis als Software 
und/oder als Hardware realisierbar ist 

3. Verfahren nach Anspruch 1, wobei eine externe 
Spezifikation vorgegeben ist, dadurch gekenn- 
zeichnet, daB die Spezifikation technologienah ge- 
wahlt wird, so daB sich solche verfahrenstechnische 
Objekte ergeben, bei denen die Funktionsbeschrei- 
bung der Strukturbeschreibung untergeordnet ist 

4. Verfahren nach Anspruch 3, dadurch gekenn- 
zeichnet, daB die Spezifikauon formal analysiert 
und simulativ validiert wird. 

5. Verfahren nach Anspruch 4, dadurch gekenn- 
zeichnet daB aus der Spezifikation ein zielmaschi- 
nenneutraler Code fur Automatisierungssysteme 
erzeugt wird 

6. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, daB zur Benutzungsanalyse eine modell- 
basierte Diagnose durchgefuhrt wird. 

7. Verfahren nach Anspruch 6, dadurch gekenn- 
zeichnet, daB bei der modellbasierten Diagnose ei- 
ne Kombination Iokaler Modelle angewandt wird 

8. Verfahren nach Anspruch 6 und 7, dadurch ge- 
kennzeichnet, daB bei Storungen, die durch Anla- 
genfehler hervorgerufen werden, Modelle des Nor- 
mal- und Fehlverhaltens von Komponenten ent- 
sprechend der Anlagenstruktur herangezogen wer- 
den. 

9. Verfahren nach Anspruch 8, dadurch gekenn- 
zeichnet, daB die Diagnosetechniken in den Anla- 
genentwurf integriert sind 

10. Rechnergestiitztes Projektierungssystem zur 
Durchfuhrung des Verfahrens nach Anspruch 1 
oder einem der Anspruche 2 bis 9, enthaltend einen 
Digitalrechner mit Zentraleinheit, Arbeits-, Pro- 
gramm- und Datenspeichern und mit Mitteln zur 
Codegenerierung, dadurch gekennzeichnet, daB 
mit dem Digitalrechner (10) gleichermaBen ein Zu- 
griff auf eine Bibliothek (11) von verfahrenstechni- 
schen Komponententypen und auf eine Beschrei- 
bung (13) der Elemente der konkreten Anlage (12) 
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erfolgt 

11. Projektierungssystera nach Anspruch 10, da- 
durch gekennzeichnet, daB die Komponentenbi- 
bliothek (1 1) Bescanteil des Datenspeichers ist 
12 Projektierungssystera nach Anspruch 11, da- 5 
durch gekennzeichnet, daB die verfahrenstechni- 
schen Komponententypen einen hierarchischen 
Aufbau bilden. 

13. Projektierungssystem nach Anspruch 10, da- 
durch gekennzeichnet, daB die Bibliothek (11) der 10 
verfahrenstechnischen Komponententypen eine 
branchenspezifische AusprSgung hat 

14. Projektierungssystem nach Anspruch 10, da- 
durch gekennzeichnet, daB die verfahrenstechni- 
schen Komponententypen aus der Sicht eines 15 
Technologen definiert sind und ein unmittelbarer 
Bezug zur ProzeBtechnik besteht 

15. Projektierungssystem nach Anspruch 14, da- 
durch gekennzeichnet, daB das Verhalten der ver- 
fahrenstechnischen Komponententypen hinsicht- 20 
lich Steuerung und/oder Regelung, ProzeBsimula- 
tion und St6rungsanalyse spezifiziert ist 

16. Projektierungssystem nach Anspruch 10, da- 
durch gekennzeichnet, daB fur eine konkrete Anla- 
ge (12) durch Instanziierung der Verfahrenstechni- 25 
schen Komponententypen der Anlagenaufbau rea- 
lisiert ist 

17. Projektierungssystem nach Anspruch 10, da- 
durch gekennzeichnet, daB die Mitte] zur Codege- 
nerierung im Programmspeicher des Rechners ge- 30 
laden sind und automatisiert arbeiten. 

18. Projektierungssystem nach Anspruch 17, da- 
durch gekennzeichnet, daB ein CSL-Compiler (30) 
vorhanden ist, der zur Codegenerierung genutzt 
wird 35 
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